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PROCEDE DE PREPARATION ET D ' EXECUTION D ' UNE PROCEDURE 
D'AUTOTEST ET PROCEDE DE GENERATION D 1 AUTOTESTS ASSOCIE 

L' invention a pour objet un precede de preparation 
et d'execution d'une procedure d'autotest et un procede 
de generation d'autotests associe, pour la verification 
fonctionnelle et de performance de circuits logiques, 
5 notamment de modeles de processeur. 

Avec le developpement croissant des systemes 
electroniques embarques utilisant des processeurs 
programmables, il y a une forte demande d ! outils fiables, 
precis et reutilisables pour developper ces processeurs. 

10 Les outiis demandes sont par exemple des compilateurs 
optimisateurs ou des modeles (egalement appeles 
simulateurs) capables de decrire bit par bit ou cycle par 
cycle le f onct ionnement du processeur pour permettre 
1 ' exploration de son architecture et sa validation. 

15 Le developpement et la mise au point d 1 un 

processeur sur circuit integre necessitent la realisation 
de simulateurs. Un simulateur est un programme qui permet 
de simuler tout ou partie du comportement du processeur 
physique qui en decoulera. Pour le developpement d 1 un 

20 meme processeur par exemple, des simulateurs de 
f onct ionnalite sont utilises pour controler le jeu 
d' instructions du processeur, et des simulateurs de 
performances sont utilises pour etudier le f onct ionnement 
global du processeur physique a realiser. Selon la 

25 complexity (en terme de f onct ionnalites ou de 
performance) du processeur physique qui doit etre 
realise, un ou plusieurs simulateurs sont developpes. 
Lorsque les simulateurs sont au point, leur derniere 
version est transformee en un circuit integre qui 

30 correspond au processeur physique. Les simulateurs sont 
en general developpes par des equipes differentes et dans 
des langages de programmation differents, le plus souvent 
pour des raisons de facilite de developpement. Dans ce 



qui suit, 1' expression "modele de processeur" sera 
utilisee pour designer de maniere generique un processeur 
et les simuiateurs crees pour le developper. 

Pour assurer la fiabilite du processeur final, il 
est indispensable, a chaque etape du developpement , de 
valider le modele de processeur obtenu a chaque etape, 
c ' est-a-dire de verifier que le modele de processeur 
(simulateur ou circuit integre final) obtenu a chaque 
etape, a bien les caracterist iques et le comportement 
souhaites. La validation se fait par 1 ' intermediaire de 
procedures de test specif iques. Par exemple, au cours 
d'une procedure de test de f onctionnalite , il est demande 
au modele de processeur d'executer une unique instruction 
de son jeu d 1 instructions pour controler son 
f onctionnement correct. De la meme fagon, au cours de 
1' execution d'une procedure de test de performance, 
plusieurs instructions sont executees successivement pour 
controler 1 1 enchainement correct des instructions. 
Generalement, plusieurs procedures de test sont 
effectuees successivement et de preference de maniere 
automatique. Une procedure de test est generalement mise 
en ceuvre sous la forme d'un programme (appele "test") 
executable par le modele de processeur a tester. 

Apres execution d'un test, un resultat est obtenu 
qui correspond par exemple au contenu des elements du 
modele de processeur apres execution du test, ou bien a 
1' evolution du contenu des elements du modele a chaque 
cycle d'horloge et pendant toute la duree d'execution du 
test. Par elements du modele de processeur, il faut 
comprendre ici des elements tels que les memoires ou les 
registres du modele a tester. Le resultat du test est en 
general memorise dans un fichier de resultat, appele 
trace de la procedure de test. Le contenu du fichier de 
resultat (type d 1 informations , ordre, ...) est defini dans 
la procedure de test. 



3 



Vu la complexity des modeles de processeur actuels, 
et done le nombre de tests a realiser pour les valider 
correctement et de maniere fiable, il n'est plus possible 
d'ecrire les procedures de test ou les tests a la main. 
5 Des procedes de generation de tests sont utilises, 

qui fournissent des procedures de test, ou des tests, en 
fonction de parametres imposes par 1 1 utilisateur . Les 
parametres sont par exemple le nom et la definition 
f onct ionnelle d'une instruction du jeu d 1 instruct ions du 

10 modele de processeur a tester, ou bien 1 1 ordre dans 
lequel deux instructions successives doivent etre 
executees. De tels procedes de generation de tests sont 
mis en ceuvre par des generateurs de tests, qui sont des. 
programmes realisant les differentes etapes des procedes 

15 associes. 

Un generateur de tests est en general developpe 
pour un modele de processeur particulier, et il fournit 
des procedures de test dans un langage comprehensible 
d'une part par le modele a tester, et d f autre part par 

20 1' interface de controle du modele et les outils utilises 
pour le developper. Actuellement pour le developpement 
d ' un meme processeur, au moins un generateur de tests est 
developpe pour chaque type de modele de processeur, par 
exemple un pour le simulateur de performance, un pour le 

25 processeur final, etc. Bien que, souvent, les tests a 
realiser sont identiques sur le fond, deux generateurs de 
tests vont fournir des procedures de test differentes, 
adaptees aux modeles de processeur auxquelles elles sont 
destinees. Pendant toute la duree du developpement du 

30 processeur, les procedures de test fournies par les 
differents generateurs de tests sont memorisees, ce qui 
necessite des capacites de stockage de donnees 
importantes . 

De plus, la trace (le resultat) fournie par une 
35 procedure de test est dependante de la maniere dont la 
procedure a ete obtenue. En particulier, deux procedures 



de test obtenues a partir de deux generateurs de tests 
differents, vont peut-etre donner des traces differences, 
en terme de type d ' information ou de format notamment . 

Par exemple, pour tester la realisation d 1 une 

5 addition C=A+B, une premiere procedure de test fournit 
une trace indiquant le contenu du registre C a la fin de 
l 1 execution du test, alors qu'une deuxieme procedure 
fournit une trace indiquant 1 ! evolution du contenu du 
registre C, tout au long de la realisation du meme test. 

10 Dans de tels cas, il n'est pas possible de comparer 
directement les deux traces, et il est necessaire de 
passer par 1 ' intermediaire d'un traducteur ou d 1 un 
interpreteur . 

De plus, la trace d'une procedure de test ne peut 

15 pas etre exploitee directement par un generateur de tests 
actuel, car il ne connait pas le resultat attendu de la 
procedure de test qu'il a genere et il ne sait pas 
l'obtenir. En consequence, il est necessaire de trier et 
valider toutes les procedures de test fournies par un 

20 generateur, afin de ne garder que les tests corrects, 
voire meme uniquement les tests dont le resultat est 
interessant pour 1 1 utilisateur . En effet, des tests 
fournis par un generateur de tests peuvent etre 
redondants, d'autres apportent tres peu d ' information, ou 

25 bien des erreurs de programmat ion apparaissent dans 
certains tests. 

Pour valider et utiliser les tests fournis par les 
generateurs de tests actuels, il est necessaire de 
connaitre le resultat attendu des procedures de test 

30 qu'ils executent . Pour cela, on utilise generalement un 
ou des modeles de processeur de reference, parfaits, qui 
fournissent le resultat attendu pour chaque test ou 
procedure de test. Pour verifier si le * modele de 
processeur a tester est correct ou pas, il faut alors 

35 comparer la trace fournie par une procedure de test 
execut.ee par le modele, avec la trace fournie par la meme 
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procedure de test lorsqu'elle est executee par un modele 
de reference . 

Des difficultes peuvent alors apparaitre pour 
effectuer la comparaison et il peut etre necessaire 
5 d 1 avoir recours a un interpreteur ou un traducteur pour 
pouvoir effectuer cette comparaison. De plus, la 
precision des generateurs de tests actuels depend de la 
precision des simulateurs de reference disponibles. Or, 
il est difficile d'obtenir des modeles de reference 
10 parfaits, qui doivent bien sur etre eux-memes valides, et 
il est encore plus difficile d ! obtenir un modele de 
reference qui soit capable d'utiliser toutes les 
instructions, toutes les f onct ionnalites d 1 un modele de 
processeur a tester. 

15 

Au vu des inconvenients des generateurs de tests 
actuels, un but de 1' invention est de mettre en oeuvre un 
precede qui permet d'obtenir rapidement des procedures de 
test et des tests utilisables pour les differents types 

20 de modeles (simulateurs ou processeur final) necessaires 
au developpement d'un raeme processeur, sans adaptation ni 
modification. Ceci limite alors le nombre de tests 
necessaires au developpement complet d'un processeur, 
e'est-a-dire a la validation de tous les modeles de 

25 processeur utilises pour son developpement, y compris le 
processeur final. Le temps necessaire a la validation de 
tous les modeles ainsi que les besoins de stockage des 
differents tests sont alors egalement reduits. 

Un autre but de l 1 invention est de mettre en oeuvre 

30 un procede qui permet a 1 'utilisateur d' obtenir des 
procedures de test et des tests qui fournissent des 
resultats sous une forme simple et directement 
exploitable avec tous les outils de developpement d'un 
meme processeur. 

35 Avec ces objectifs en vue, 1 1 invention a pour objet 

un procede de preparation et d' execution d'une- procedure 
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d'autotest pour valider le comportement d'un modele de 
processeur a tester, le modele de processeur etant un 
processeur ou un simulateur associe, le procede etant 
caracterise en ce qu'il comprend les etapes suivantes, 
5 consistant a : 

- recevoir des specifications (E2) d 1 un utilisateur 
concernant au moins une instruction a tester d 1 un jeu 
d 1 instructions du modele de processeur, 

- lire (E4), dans une table, des donnees 
10 caracteristiques du modele de processeur a tester, les 

donnees comprenant notamment une definition f onctionnelle 
de 1 1 instruction a tester et une definition f onctionnelle 
des elements du modele de processeur, 

- calculer un resultat attendu (E6) a la fin de 
15 I 1 execution de 1 ' instruction a tester, le calcul etant 

realise a partir des specifications de 1 ' utilisateur et 
des donnees caracteristiques du modele de processeur, et 

- faire realiser, par le modele a tester, une 
procedure d'autotest (E8) pour valider 1 1 instruct ion a 

20 tester, la procedure d'autotest fournissant en retour un 
mot de resultat qui est egal a une premiere valeur (OK) 
si le comportement du modele de processeur est correct, 
et qui est egal a une deuxieme valeur (ERROR) sinon. 

Ainsi, avec 1' invention, le resultat est 

25 directement exploitable par 1 ' utilisateur , sans 
•necessiter d'etape de comparaison ou de traduction 
complementaire par exemple. Un resultat egal a OK 
signifie en general d 1 une part que la procedure 
d'autotest E8 est correctement mise en oeuvre, et d' autre 

30 part que le modele de processeur sous test reagit 
correctement par rapport a la ou les instructions a 
executer . 

Inversement, un resultat egal a ERROR signifie soit 
que le modele de processeur n'est pas correct par rapport 
35 aux specifications attendues, soit que la procedure 
d'autotest n'est pas correctement mise en oeuvre (choix 
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peu judicieux des instructions a tester, erreur 
d'ecriture pour la mise en ceuvre de la procedure, 
parametres incorrects, etc. ) . 

De preference, la procedure d'autotest (E8) 
5 comprend les sous-etapes suivantes, consistant a: 

- initialiser (E81) des elements du modele de 
processeur a tester, 

- executer 1 1 instruction a tester (E82), et 
obtenir un resultat, 

10 - comparer le resultat obtenu (E83) et le 

resultat attendu, et 

- fournir (E84) un mot de resultat de la 
comparaison (OK/ERROR) . 

Selon une variante, une seule instruction du jeu 
15 d ' instructions du modele de processeur est executee, ce 
qui permet de tester le comportement fonctionnel du 
modele. Selon une autre variante, au moins deux 
instructions du jeu d 1 instructions du modele de 
processeur sont executees successivement , pour valider 
20 les performances du modele de processeur a tester. 

Ainsi, une procedure d'autotest est une procedure 
de test englobant une initialisation des elements 
(registres et/ou memoires) du modele de processeur a 
tester, une ou plusieurs instructions a executer, un 
25 calcul d ! un resultat attendu et une comparaison du 
resultat attendu avec un resultat obtenu apres execution 
de la ou des instructions a executer, la procedure de 
test fournissant un resultat simple a interpreter, de 
type vrai/faux. 

30 Une procedure d'autotest est done une procedure de 

test qui est autonome car elle est executee sans autre 
instruction qu 1 une instruction de debut et elle n ! a pas 
besoin d'etre validee avant d'etre utilisee. Avec 
1' invention, il n'est done plus necessaire de disposer de 

35 modele de reference pour valider les procedures 
d ' autotests . 
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Selon un autre mode de realisation de 1' invention, 
le procede comprend les etapes suivantes, consistant a : 

- faire realiser, par le modele a tester, une 
procedure d'autotest (E8) et recevoir un mot de resultat, 

5 - prendre une decision (E10) : si le resultat 

precedent est egal a la premiere valeur alors realiser 
une etape E12, sinon, si le resultat precedent est egal a 
la deuxieme valeur (ERROR), realiser une etape E14, 

- prendre une decision (E12) : si une autre 
10 procedure d'autotest doit etre executee, alors realiser 

une nouvelle etape E8, sinon, fin du procede, et 

- memoriser (E14) des informations relatives a la 
procedure d'autotest precedemment effectuee, les 
informations contenant notamment une adresse a laquelle 

15 une erreur a ete detectee, puis fin du procede. 

De preference, les etapes E8 a E14 sont precedees 
des etapes d 1 initialisation suivantes : 

- recevoir des specifications d'un utilisateur 
(E'2) concernant au moins deux procedures d'autotest, 

20 - lire (E ! 4), dans une table, des donnees 

caracteristiques du modele de processeur a tester 
necessaires a 1' execution des procedures d'autotest, 

- executer (E f 6) plusieurs etapes E6, de maniere 
successive, chaque etape (E6) correspondant a une 

25 procedure d'autotest. 

Ce mode de realisation presente 1 ' avantage 
d' executer plusieurs procedures d'autotests successives, 
ce qui limite 1 ' intervention de 1 1 utilisateur , s'il le 
souhaite, au cas ou une procedure d'autotests donne un 

30 resultat incorrect. 

De preference, apres 1 ' etape E'6, une etape E7 est 
realisee, qui fournit a 1 ' utilisateur une etude 
statistique des instructions a tester lors des etapes E8 
suivantes. L ' utilisateur sait ainsi precisement quelles 

35 instructions vont etre testees, combien de fois chaque 
instruction ou combinaison d ' instructions va etre 



9 



executee, en d'autres termes, il connait precisement, 
pour l 1 ensemble des procedures d'autotests qui vont etre 
executees, la couverture du jeu d 1 instruct ions et des 
performances du modele de processeur a valider. 
5 De la meme fagon, une etape E16 peut egalement etre 

realisee a la fin du procede, qui fournit une etude 
statistique des resultats fournis lors de toutes les 
procedures d'autotests executees par le modele sous test. 

L' invention a egalement pour objet un procede de 
10 generation de programmes d'autotest, caracterise en ce 
qu'il comprend les etapes E2 a E6 du procede precedemment 
decrit, et en ce qu'il comprend en outre 1 1 etape E ! 8 
suivante : 

- ecrire un programme d'autotest pour faire 
15 executer une procedure d'autotest par le modele de 
processeur . 

Ce programme, memorise, peut etre utilise 
ulterieurement par le modele de processeur a tester. Pour 
cela, le programme d'autotest est de preference ecrit 

20 dans un langage de type assembleur, comprehensible par 
tous les modeles a tester d'un meme processeur et les 
etapes d f initialisation sont realisees a partir 
d 1 instructions du jeu d ' instruct ions du modele a tester, 
tous les modeles d'un meme processeur ayant le meme jeu 

25 d 1 instructions . Une meme procedure d'autotests selon 
1' invention est ainsi utilisable par tous les modeles 
d'un meme processeur ; le nombre de procedures 
d'autotests a developper est done limite de fait 
puisqu'il n'est pas necessaire de developper des 

30 procedures specif iques pour chaque modele. Le temps de 
realisation des procedures d'autotests est done limite, 
ainsi que les besoins de stockages de ces procedures. 

De plus, une meme procedure d'autotests pouvant 
etre effectuee par des modeles de processeurs differents, 

35 1 ' utilisateur n'a plus besoin de passer par 
1 1 intermediaire d'un interpreteur ou d'un traducteur pour 
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comparer deux resultats d' un meme autotest, realises sur 
deux modeles de processeur differents par exemple . 

De preference enfin, le procede de generation 
d'autotests de 1' invention est mis en ceuvre sous la forme 
5 d'un programme ecrit dans un langage evolue de type DGL 
et/ou C++, comprehensible par 1 ' utilisateur , ce qui 
facile le travail de developpement et de mise en ceuvre de 
ce procede . 

L 1 utilisateur peut alors, par des modifications 
10 simples, obtenir facilement des procedures d'autotests et 
des autotests pour tout type de modeles de processeur, 
pour le developpement de nouveaux processeurs par 
exemple . 

15 L' invention sera mieux comprise et d'autres 

caracteristiques et avantages apparaitront a la lecture 
de * la description qui va suivre, la description faisant 
reference aux dessins annexes dans lesquels : 

- la figure 1 est un diagramme d'un algorithme de 
20 mise en ceuvre d'un procede de preparation et d 1 execution 

d'une procedure d 1 autotest, selon I 1 invention, 

- la figure 2 est un diagramme detaillant une etape 
de l 1 algorithme de la figure 1. 

- la figure 3 montre des ameliorations possibles de 
25 l 1 algorithme de la figure 1. 

Le procede de la figure 1, selon 1 ! invention, est 
utilise pour preparer et executer une procedure 
d' autotest, dans le but de tester le comportement (en 

30 terme de f onct ionnalite ou de performance) d'un 
processeur a valider ou d 1 un simulateur associe, un 
simulateur etant un modele qui permet de simuler le 
comportement du processeur. 

Le procede est par exemple mis en oeuvre par une 

35 interface de commande, de type unite centrale ou station 
de travail, qui pilote le f onct ionnement et les 
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operations de tests du modele a tester qui lui relie, 
sous la forme d ! un programme a tester (simulateur) ou 
d'un circuit (processeur physique) a tester. 

Comme precedemment, on utilisera par la suite 
1' expression "modele de processeur" pour designer de 
maniere generale un processeur ou un simulateur 
correspondant . 

Le procede de la figure 1 comprend une etape E2 de 
reception de specifications, une etape E4 de lecture de 
donnees, une etape E6 de calcul d'un resultat attendu et 
une etape E8 de realisation d'une procedure d'autotest, 
cette derniere etape etant executee par le modele sous 
test . 

Au cours de la realisation de 1' etape E2, 
1 ' utilisateur precise quel type de test il souhaite 
effectuer, et en particulier quelle (s) instruct ion ( s ) 
doivent etre executees par le modele de processeur a 
tester. La ou les instructions a tester sont bien sur des 
instructions du jeu d ' instruct ions du modele sous test, 
ces instructions etant a priori les seules qu f il peut 
executer. L ' utilisateur choisit par exemple une unique 
instruction s f il souhaite realiser un test de 
f onctionnalite du jeu d 1 instruct ions du modele a tester, 
c'est-a-dire s' il souhaite verifier que 1 1 instruct ion 
choisie est executee correctement par le modele a tester. 
L 1 utilisateur peut egalement choisir deux instructions ou 
plus, s f il souhaite effectuer un test de performance du 
modele de processeur, en precisant dans quel ordre 
doivent etre executees les instructions choisies. 

Au cours de 1 1 etape E2, 1 1 utilisateur precise 
egalement les valeurs initiales a prendre en compte pour 
executer les instructions precedemment choisies. Par 
exemple, si 1 f utilisateur souhaite voir executer 
l 1 addition C=A+B, alors il va preciser les valeurs 
numeriques de A et B et les registres dans lesquels elles 
doivent etre memorisees, le nom de 1 1 instruction a 



utiliser ADD, au moins une adresse pour indiquer ou doit 
etre memorise le resultat, s'il est memorise, et 
eventueilement une adresse ou doit etre memorise un 
eventuei debordement de capacite. 

5 Au cours de 1 ' etape E2, 1 ' utilisateur definit enfin 

quelles informations il souhaite obtenir en retour apres 
execution de la ou des instructions. Dans le cas d 1 une 
addition, 1 1 utilisateur peut par exemple preciser qu'il 
souhaite obtenir le contenu des registres de resultat et 

10 savoir si un eventuei debordement de capacite a eu lieu. 
II peut egalement choisir de demander une information sur 
l 1 evolution du contenu de tous les registres du modele a 
tester, cycle par cycle, au cours de 1' execution de 
1 1 instruction choisie . 

15 Au cours de 1 1 etape E4 , des parametres, 

correspondant a des caracteristiques techniques du modele 
de processeur a tester, sont lus dans une table de 
caracteristiques. Les parametres lus comprennent 
notamment une description f onct ionnelle et 

20 comportementale de la ou des instructions a executer, une 
liste des elements du modele de processeur a utiliser 
pour executer la ou les instructions, et egalement une 
description fonctionnelle de ces elements, incluant leur 
adresse, leur taille, etc. Les parametres lus dependent 

25 bien sur des specifications de 1 1 utilisateur precisees 
dans 1' etape E2 . 

La table de caracteristiques contient toutes les 
caracteristiques techniques du modele de processeur sous 
test. La table comprend notamment une description 

30 fonctionnelle et comportementale precise de tous les 
elements du modele (nombre de registres, de memoire, 
d'unites de calcul, etc., taille, adresses de tous les 
elements, connexions les uns aux autres, etc.). La table 
comprend egalement une description complete du jeu 

35 d 1 instructions du modele et des regies de compilation 
associees . 
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Toutes les informations contenues dans la table 
peuvent etre fournies par 1 ? utilisateur , lors d 1 une etape 
EO (non representee sur la figure 1) d 1 initialisation du 
procede par exemple. Toutes ces informations peuvent 
egalement etre obtenues et memorisees par ailleurs, dans 
une me moire . 

Au cours de 1 1 etape E6, un resultat theorique est 
calcule, qui correspond au resultat a attendre si le test 
est effectue correctement et si le modele a tester est 
correct. Le resultat theorique calcule depend, d'une part 
des specifications de 1 1 utilisateur precisees au cours de 
1 ! etape E2, et d' autre part des caracterist iques 
techniques du modele sous test lues au cours de 1 1 etape 
E4 Le resultat attendu est ainsi calcule directement a 
partir des caracterist iques du processeur. II n'est done 
pas necessaire de disposer d f un modele de processeur de 
reference pour obtenir ce resultat attendu, ce qui est 
particulierement avantageux . 

Dans le cas de 1' addition C=A+B decrit ci-dessus, 
le resultat theorique calcule comprend le nombre C sous 
forme binaire qui doit etre contenu dans les registres de 
resultat si le test est bon, et le contenu d'un registre 
indiquant si un depassement de capacite doit avoir lieu. 

Les etapes E2, E4 et E6 ci-dessus preparent la 
realisation de la procedure d'autotest E8 suivante, qui 
est executee par le modele a tester, selon les 
instructions de l 1 interface de commande qui met en ceuvre 
le procede de l 1 invention. 

La procedure d'autotest E8 comprend, conformement a 
la figure 2, une etape d 1 initialisation E81, une etape 
d ! execution d 1 instructions E82, une etape d' etape de 
comparaison E83 et une etape de fourniture de resultat 
E84 . 

Au cours .de 1 ' etape d 1 initialisation E81, tous les 
elements (registres, memoires, circuits de calcul, etc.) 
du modele de processeur sous test sont initialises. Par 
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exemple, les valeurs initiales, si elles existent, sont 
chargees dans les registres correspondants, les registres 
ne recevant pas de valeur initiale regoivent un zero, les 
circuits de calcul sont initialises, etc. 

5 Au cours de 1 ' etape d 1 execution d 1 instruct ions £82, 

la ou les instructions a tester sont executees, 
conf ormement aux specifications de 1 ' ut ilisateur 
precisees dans 1 ' etape E2, et un resultat est extrait du 
modele sous test. Les informations extraites sont celles 

10 precisees par 1 ' utilisateur au cours de 1 1 etape E2 . Par 
exemple, dans le cas de 1' operation C=A+B, le resultat 
obtenu comprend le nombre C, contenu dans un ou plusieurs 
registres de resultat, et une information indiquant si un 
depassement de capacite a eu lieu ou pas lors de la 

15 realisation de 1 1 etape E82 . 

Lors de la realisation de l 1 etape E83 suivante, une 
comparaison est effectuee, entre le resultat calcule au 
cours de 1 1 etape E6 et le resultat reellement obtenu au 
cours de 1 1 etape E82. 

20 Un resultat de la comparaison est finalement fourni 

(etape E84), et eventuellement memorise. Le resultat de 
la comparaison prend deux valeurs, qui sont par exemple 
OK si la comparaison indique que les resultats attendu et 
obtenu sont les memes, et ERROR dans le cas contraire. 

25 Un resultat egal a OK signifie en general d 1 une 

part que la procedure d'autotest E8 est correctement mise 
en oeuvre, et d 1 autre part que le modele de processeur 
sous test reagit correctement par rapport a la ou les 
instructions a executer. 

30 Inversement, un resultat egal a ERROR signifie soit 

que le modele de processeur n'est pas correct par rapport 
aux specifications attendues, soit que la procedure 
d'autotest n'est pas correctement mise en oeuvre (choix 
peu judicieux des instructions a tester, erreur 

35 d'ecriture pour la mise en oeuvre de la procedure, 
parametres incorrects, etc.). 
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Le diagramme de la figure 1 decrit ci-dessus montre 
une realisation simple d'un procede de preparation et 
d' execution d'une procedure d'autotest, selon 
5 1 ! invention. Dans un mode prefere de realisation, une 
procedure d'autotest E8 est mise en oeuvre sous la forme 
d'un programme d'autotest (plus simplement appele 
autotest ) . 

L'exemple simple de la figure 1 peut etre ameliore 
10 de differentes manieres, sans sortir du cadre de 
1 ' invention. Des ameliorations possibles sont 

representees sur la figure 3. 

Une premiere amelioration permet d'effectuer 
plusieurs procedures d'autotest E8 successivement, de 
15 maniere automatique, ce qui permet un gain de temps 
considerable . 

Au cours de 1 ' etape E'2, 1 ' ut ilisateur precise, 
comme precedement, 1 ! ensemble des instructions a tester, 
l'ordre dans lequel elles doivent etres testees, les 
20 valeurs initiales a prendre en compte et les resultats a 
extraire, ceci pour chaque procedure d'autotest a 
ef f ectuer . 

Au cours de 1' etape EM, tous les parametres 
necessaires a la realisation de toutes les procedures 
25 d'autotest sont lus dans la table. 

Au cours de 1 1 etape E'6, sont calcules de maniere 
successive, les resultats attendus pour chaque procedure 
d 1 autotest . 

Les etapes E'2, EM et E'6 decrites ci-dessus 
30 preparent la realisation des etapes E8, E10, E12 et E14 
suivantes . 

Une premiere etape E8 est realisee, identique a 
celle decrite dans l'exemple simple de la figure 1. Une 
premiere etape de decision E10 est ensuite realisee. 
35 Si le resultat de 1 1 etape E84 precedente est 

correct (OK) , alors une deuxieme etape de decision E12 
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est effectuee, pour verifier si une nouvelle procedure 
d'autotest E8 doit etre effectuee ou pas. 

Si le resultat de 1 1 etape E12 est positif, alors 
une nouvelle etape E8 est effectuee. Dans le cas 
5 contraire, le procede se termine. 

Si le resultat de 1 1 etape E84 precedente est 
mauvais (ERROR) , alors une etape E14 de memorisation est 
effectuee, au cous de laquelle des informations relatives 
a la procedure d'autotest incorrecte sont memorisees. Les 
10 informations comprennent notamment I'adresse ou 1 ' erreur 
a ete detectee. Ces informations sont obtenues a partir 
de l'etat architectural du processeur sous test. 

Le procede se termine alors a la fin de 1 1 etape de 
memorisation E14. Ainsi le procede se termine des qu 1 une 
15 procedure d'autotest fournit un mauvais resultat. 
L 1 ut ilisateur sait alors immediatement quelle procedure 
d'autotest pose probleme ou quelles f onct ionnalite et / 
ou performance du modele sous test ne sont pas conformes 
a ses souhaits. 

20 Dans un mode prefere de realisation, 1 1 ensemble des 

etapes E8, E10, E12 et E14 est mis en oeuvre sous la forme 
d'un programme d'autotest, plus simplement appele 
autotest. 

Selon une variante du procede de la figure 3, 
25 1* etape de decision E12 est egalement realisee apres 
l 1 etape de memorisation E14 (ajout de la liaison en 
pointilles entre 1' etape E14 et E12 sur la figure 3, et 
suppression de la liaison entre les etapes E14 et E16 ) . 

Dans ce cas, toutes les procedures d'autotest E8 du 
30 procede sont effectuees, quel que soit le resultat (OK / 
ERROR) de 1 1 une de ces procedures E8 . De plus, chaque 
fois qu'une procedure E8 donne un mauvais resultat ERROR, 
alors les informations relatives a cette procedure sont 
memorisees (etape E14). Le procede se termine lorsque 
35 toutes les procedures d'autotest E8 ont ete realisees. 
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L ' ensemble des informations memorisees ' au cours de 
la realisation des etapes E14 permet a 1 1 utilisateur de 
voir ulterieurement quelle procedure d 1 autotest pose 
probleme . 

5 Le procede de la figure 3 est ameliore par l'ajout 

d 1 etapes E7 et / ou E16 de fourniture de statistiques 
(representees en pointilles sur la figure 3), qui sont 
notamment interessantes lorsque plusieurs procedures 
d'autotest sont effectuees successivement . 

10 Au cours de I'etape El, est effectuee apres 1 'etape 

E'6 de calculs des resultats attendus, une etude 
statistique de 1' ensemble des instructions qui seront 
utilisees lors de la realisation des etapes d'autotest E8 
suivantes. Ce resultat permet notamment a 1 1 utilisateur 

15 de connaitre la couverture des instructions testees, 
c'est-a-dire de repondre notamment a des questions de 
type : nombre de fois ou une meme instruction est 
utilisee ? toutes les instructions du jeu d 1 instruct ions 
du modele de processeur sont-elles utilisees ? toutes les 

20 combinaisons de deux (ou plus) instructions sont-elles 
testees ?, etc. 

De maniere similaire, I'etape E16 fournit une etude 
statistique des resultats des procedures d'autotest 
precedement effectuees et donne a 1 ' utilisateur une 

25 reponse a des questions de type : nombre de procedures 
d'autotest fournissant un resultat mauvais ? quelles 
instructions sont utilisees par les procedures qui 
fournissent un resultat mauvais ? etc. 

De telles etudes statistiques ne sont pas 

30 indispensable a la mise en ceuvre de 1 ! invention, mais 
elles aident 1 1 utilisateur dans ses choix de procedures 
d'autotest a effectuer. Elles lui permettent egalement de 
determiner si le modele de processeur sous test repond 
aux specifications attendues ou pas. 



35 
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Comme il a ete dit precedement, une procedure 
d'autotest telle que l'etape E8 du procede de la figure 1 
est mis en ceuvre sous la forme d 1 un programme d'autotest, 
ou autotest . 

Pour cela 1' invention a egalement pour objet un 
procede de generation d'autotest qui comprend les etapes 
E2, E4, E6 telles que celles decrites en relation avec la 
figure 1, et qui comprend en outre une etape E'8 
d'ecriture d'un programme d'autotest pour executer une 
procedure d'autotest comportant les sous - etapes E81 a 
E84 precedement decrites. 

Bien sur, si un programme d'autotest doit etre 
realise pour le procede de la figure 3, il prendra en 
compte 1' ensemble des etapes E8, E10, E12 et E14 a 
realiser . 

De preference, le procede de generation d'autotest 
fournit des autotests ecrits dans un langage de type 
assembleur, qui presente 1 1 avantage d'etre executable par 
l f ensemble des modeles de processeur a tester, 
simulateurs utilises pour le developpement ou bien 
processeur final par exemple. 

Pour un meme processeur, deux modeles de processeur 
ont les memes caracteristiques techniques. Aussi, avec 
1' invention, il n'est alors plus necessaire d'ecrire des 
autotests differents pour des modeles differents, ce qui 
permet de reduire considerablement le temps necessaire 
pour realiser ces autotests, ainsi que les capacites de 
stockage necessaires pour les memoriser. 

De plus, si un nouveau processeur doit etre 
developpe, alors il suffit de modifier les parametres de 
la table de caracteristiques utilisee au cours de l'etape 
E4, puis d' executer une nouvelle fois le procede de 
generation d' autotests, pour obtenir simplement et 
rapidement des autotests pour le nouveau processeur et 
ses modeles associes. 
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REVENDICATIONS 

a 1. Procede de preparation et d 1 execution d'une 
procedure d'autotest pour valider le comportement d'un 
modele de processeur a tester, le modele de processeur 
etant un processeur ou un simulateur associe, le procede 

5 etant caracterise en ce qu'il comprend les etapes 
suivantes, consistant a : 

_ recevoir des specifications (E2) d 1 un utilisateur 
concernant au moins une instruction a tester d'un jeu 
d 1 instructions du modele de processeur, 

10. - lire (E4), dans une table, des donnees 

caracteristiques du modele de processeur a tester, les 
donnees comprenant notamment une definition fonctionnelle 
de 1 1 instruction a tester et une definition fonctionnelle 
des elements du modele de processeur, 

15 - calculer un resultat attendu (E6) a la fin de 

1' execution de 1 1 instruction a tester, le calcul etant 
realise a partir des specifications de 1 1 utilisateur et 
des donnees caracteristiques du modele de processeur, et 

- faire realiser, par le modele a tester, une 

20 procedure d'autotest (E8) pour valider 1 1 instruct ion a 
tester, la procedure d'autotest fournissant en retour un 
mot de resultat qui est egal a une premiere valeur (OK) 
si le comportement du modele de processeur est correct, 
et qui est egal a une deuxieme valeur (ERROR) sinon. 

25 

©2. Procede selon la revendicat ion 1, caracterise en 
ce que la procedure d'autotest _ (E8) comprend les sous- 
etapes suivantes, consistant a: 

- initialiser (E81) des elements du modele de 
30 processeur a tester, 

- executer 1 1 instruct ion a tester (E82), et 
obtenir un resultat, 

- comparer le resultat obtenu (E83) et le 
resultat attendu, et 



- fournir (E84) un mot de resultat de la 
comparaison (OK/ERROR) . 



n 3. Procede selon 1 1 une des revendicat ions 1 a 2, 
caracterise en ce qu'au moins deux instructions du jeu 
d' instructions du modele de processeur sont executees 
successivement, pour valider les performances du modele 
de processeur a tester. 

& 4. Procede selon la revendicat ion 1, caracterise en 
ce qu'il comprend les etapes suivantes, consistant a : 

- faire realiser, par le modele a tester, une 
procedure d'autotest (E8) et recevoir un mot de resultat 
(OK / ERROR) , 

- prendre une decision (E10) : si le resultat 
precedent est egal a la premiere valeur (OK) alors 
realiser une etape E12, sinon, si le resultat precedent 
est egal a la deuxieme valeur (ERROR) , realiser une etape 
E14, 

- prendre une decision (E12) : si une autre 
procedure d'autotest doit etre executee, alors realiser 
une nouvelle etape E8, sinon, fin du procede, et 

- memoriser (E14) des informations relatives a la 
procedure d'autotest precedemment effectuee, les 
informations contenant notamment une adresse a laquelle 
une erreur a ete detectee, puis fin du procede. 

0 5. Procede selon la revendicat ion 4, caracterise en 
ce qu'il comprend en outre les etapes d 1 initialisation 
suivantes, a executer avant la premiere etape E8 : 

- recevoir des specifications d'un utilisateur 
(E ! 2) concernant au moins deux procedures d'autotest, 

- lire (E'4), dans une table, des donnees 
caracteristiques du modele de processeur a tester 
necessaires a l 1 execution des procedures d'autotest, 
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- executer (E'6) plusieurs etapes E6, de maniere 
successive, chaque etape E6 correspondant a une procedure 
d 1 autotest . 



5 6. Procede selon 1 1 une des revendicat ions 4 ou 5, 

caracterise en ce qu'il comprend en outre l 1 etape E7 
suivante, executee apres l 1 etape E f 6, et consistant a : 

- fournir une etude statistique (E7) des 
instructions a tester lors des etapes E8 suivantes, pour 
10 estimer la couverture du jeu d ■ instruct ions et des 
performances du modele de processeur a valider. 

7. Procede selon 1 ' une des revendicat ions 4 a 6, 
caracterise en ce qu ! il comprend en outre I 1 etape E16 
15 suivante, effectuee a la fin du procede et consistant a : 

fournir une etude statistique (E16) des 
resultats (OK / ERROR) fournis lors de toutes les 
procedures d'autotests (E8) executees par le modele a 
tester . 

20 

„ 8. Procede de generation de programmes d* autotest, 
caracterise en ce qu'il comprend les etapes E2 a E6 du 
procede selon 1 1 une des revendicat ions 1 a 7, et en ce 
qu f il comprend en outre I 1 etape E'8 suivante : 
25 - ecrire (E'8) un programme d 1 autotest pour faire 

executer une procedure d'autotest (E8) par le modele de 
processeur . 



r 9. Procede selon la revendication 8, caracterise en 
30 ce que lors de la realisation de 1 1 etape E f 8, le 
programme d'autotest est ecrit dans un langage . de. type 
assembleur, comprehensible et executable par tous les 
modeles a tester d'un meme processeur. 
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a 10. Procede selon 1 * une des revendicat ions 8 ou 9, 
caracterise en ce que 1 1 etape E81 est realisee a partir 
d 1 instructions du jeu d 1 instructions du modele a tester. 

* 11. Procede selon 1 1 une des revendicat ions 8 a 10, 
caracterise en ce qu ! il est mis en oeuvre sous la forme 
d'un programme ecrit dans un langage evolue de type DGL 
et/ou C++, comprehensible par 1 f ut ilisateur . 
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